∂03-JUL-75  0859		E,ALS
 This is a repeat message as my earlier one seems to have been lost
 The query in Etv was put in at REG's request to guard the unwary from foolish
 mistakes. If you keep a back-up copy od a file on another area under the same
 name (as I sometimes do) then maybe the message still serves a useful purpose.
␈ CC: mjc

∂27-JUN-75  0909		E,ALS
 I have a reasonable fix of the /F/R problem up as RU ETV[E,ALS]. It has the
 following bug or feature, depending on how you look at it. After a /F/R
 reference, a switch to another file and a return αβ#λ one gets back OK but
 for a return αβ#ε one loses the /F along with the /R. Maybe this is as it should
 be but one is told that the old directory is invalid when it may or may not be.
 I am thinking of putting this up on the system because it is an improvement on
 what is now up. Any suggestions?
␈ CC: ME

∂13-JUN-75  1103		E,ALS
 A new feature on RU ETV[E,ALS] which I will clean up if people think it is
 worth while. The line number from the page which would correespond th the
 top and bottom rows (*** or ---) appears to the left on these lines. I could
 also add the total number of lines on the page to the bottom line, making
 the XL command unnecessary.
␈ CC: ME

∂13-JUN-75  0811		E,ALS
 Yes, I do know the game. It's English name is, of course, MILL. It is played more
 in Scandinavia than in Germany. I once had a graduate student program this but
 he did not do a very good job (it was only a term paper project), and so I made
 no effort to save it.	ALS
␈ CC: jfs

∂12-JUN-75  1404		E,ALS
 I have a bone to pick with yoou about the ETV-MAIL interface. Mail tells people
 the one can switch to ETV with a M command and that XRUN will get you back.
 Unfortunately this does not work if you have switched files while in ETV. It
 seems that you will either get thrown off or ETV will go into a loop, depending
 on whether you have switched back to the original file or not. XRUN normally
 takes some text but apparently you have done something so that the return
 address is remembered. Tell me how it works.
␈ CC: BH

∂12-JUN-75  1006		E,ALS
 You seem to have more trouble with ETV giving warnings that NEXT DIRECTORY POINTER
 INVALID -- PROCEED WITH CAUTION than most other people. Could you perhaps give
 me a clue as to why? Perhaps it might help if you could come in to my office
 and demonstrate what you have been doing that coused the trouble. You always seem to be editing PAPER[1,MG] when it happens.
␈ CC: mg

∂12-JUN-75  0952		E,ALS
 I would like to delay saving file names on file switching in ETV until they
 have been successfully looked up. Unfortunately this would interfere with
 your "." saving scheme. The problem is that if one types a nonsense file name
 it now gets saved. Also if one overtypes a good name (forgetting that one
 had already saved the name the good name gets overwritten with the bad. I
 tried to fix this in a very simple way by zeroing out the name when bad but
 this has the effect that if the good name overwritten happened to be number 0
 or at any rate low on the list then the ∃ command no longer can find files
 having higher numbers. Correction, the trouble on overwriting only happens
 if the name is mostly correct an so is identified as the same but then one
 does something foolish as to wrong switches or wrong format.
 
␈ CC: SGK

∂12-JUN-75  0855		E,ALS
 
 
 MAIL DAV
 Correction to my message- your last command was an XCAncel to cancel the corrections
 not to switch pages as I think I said.
␈ CC: DAV

∂12-JUN-75  0835		E,ALS
 You got thrown off of ETV yesterday at 17:12. Can you tell me the circumstances.
 in particular was the XCANCEL command correctly executed or were you thrown off
 before this was done? It looks to me like you ran a program called PPSAV.TMP
 which did something that I have no record of, and then gave the command HOME
 bringing something in the ATTACH buffer which you then deposited. This must have
 had about 210 characters plus the amount you then deleted with a line delete
 command. Then you tried to delete a page mark and it blew. I have seen this
 particular bug only once before and this was before I had such complete
 reporting so I was unable to track it down.	ALS
␈ CC: DAV

∂10-JUN-75  1313		E,ALS
 It seems to work! Do you want to test it before I put it up.
␈ CC: ME

∂09-JUN-75  1248		E,ALS
 Iam back from lunch.
␈ CC: RF

∂09-JUN-75  1038		E,ALS
 You might look in to the new file switches as one means of avoiding trouble
 with invalid directory pointers. Type <CONTROL>? when in ETV and see page 21.
␈ CC: BES

∂09-JUN-75  0833		E,ALS
 I am trying to work on your bug and I simply can not make it happen. There must
 be something different about the way I try to do it from the way you do. Would you
 like to come in and demonstrate again. PDQ has reported the same kind of bug so 
 I think that there is one for sure but unless I can reproduce it I have very little
 chance of fixing it. In case this does not ring bells I am talking about the 
 SOS bug with file GEYEG.YID[MAP,RF).
␈ CC: RF

∂06-JUN-75  2142		E,ALS
 Could a change in code in SOSCK2+11 WHICH I MADE cause trouble.
 This line was  JRST 2,@[20000,,(Q)] AND I have changed it to
 JRST [AOS SOSLI2 <double arrow> JRST 2,[20000,,(Q)]]
 where, of course the DOUBLE ARROW was just that which I do not know
 how to make on this tty. Could this do something different in the way
 it resets flags?  The SOS bug seems to date from about the time that I
 made this change. The purpose was to count the number of times
 one went through this bit of code. This is on page 127, in case
 you want to look at it.
␈ CC: ME

∂06-JUN-75  1332		E,ALS
 more- I can help matters some if when I write ZDATA from the EDFIL locations I check
 for the /f only case and overwrite the appropiate cell where EDFIL-2 gets written
 with zero. This may still not be enough however since I do not save the /R flag
 and so one could read a file with /F/R, switch then come back with a numbered ε
 whereupon it would have remembered the /F. Oh me!
␈ CC: me

∂06-JUN-75  1326		E,ALS
 I am back. If, as you say TMPCOR remembers the string then your explanation may
 not be complete since I do not set up the /N actually but only set the flag
 word that the /N would set. However the tempcor must be written before the
 code for /F is executed while Edfil-2 is still set up and before it has been
 put back to zero, so that whether TMPCOR gets the data from the ASCII string or
 from the flag word it is still wrong for the /F only case.
␈ CC: me

∂06-JUN-75  0857		E,ALS
 Try reading the file CPU.WL[282,LCH] WITH THE SWITCHES /F/R, that is type
 ET CPU.WL/F/R and you may be able to read the file without trouble. It seems that
 this file is not properly formatted for use with ETV.
␈ CC: LCW

∂06-JUN-75  0848		E,ALS
 Can you tell me what caused the trouble just now?
␈ CC: lcw

∂05-JUN-75  2232		E,ALS
 I put the message in twice just to mage sure that it was seen.
 I had expected the /R mode not to say anything about keeping
 the directory. There is a problem in that the same bit of code is
 used for several purposes and it is getting so laden with conditional
 tests for the several options that I am having trouble keeping every
 thing straight.  Maybe we should look at the SOS case togaather.
␈ CC: rf

∂05-JUN-75  1619		E,ALS
 YOU MIGHT LIKE TO TRY MY NEW VERSION RU ETV[E,ALS] which has a new switch
 /F or /F/R which limit the number of lines on a page to a default value of 33.
 /52F sets the line count to 52 etc. /F alone reformats your file while /F/R
 puts pseudo page marks in your core version only without affecting the disk
 copy. This should be useful for reading long files.
␈ CC: bpm

∂05-JUN-75  1612		E,ALS
 You might like to try RU ETV on E,ALS. I haven't tried it on SOS files but it may
 be that your bug has gone away. If it has not that will be the next item on my
 list. The new commands or rather switches are /F/R which repages readonly to a
 default page length of 33 lines, and /F alone which reformats the file with a 
 maximum line length of 33 words. In both cases the old page marks are still
 respected as well. /52F is the way to specify 52 lines etc.
␈ CC: rf

∂05-JUN-75  1056		E,ALS
 That is bad news for sure since it used to not do this. I will have to look into it.
 
␈ CC: RF

∂05-JUN-75  1054		E,ALS
 DO YOU MEAN WITH THE SYSTEM VERSION OF ETV?
␈ CC: RF

∂05-JUN-75  0812		E,ALS
 I have found an easy way to increase the allowable number of pages to any desired
 number as long as one is willing to forgo the use of MARKS on pages with higher
 than 511 number. I hather hate to do this however since it might encourage people
 to make and use very large files which will bother them more than others but
 which is still not a good idea. I am inclined to leave the limit where it is altho
 it would do no harm to increase it to 510 (reserving 511 for an existing function)
 
␈ CC: JFR

∂04-JUN-75  1340		E,ALS
 ETV was not designed to handle lines with more than 511 characters, ges with
 more than 511 lines and files with more than 511 pages. It keeps such numbers
 frequently in 9-bit bytes and it is a major undertaking to redo everything
 that is so dependent. I hate to think of the complications since this technique
 is so intertwined with the entire program. Why do you keep such a file in one
 piece? When I have delt with big files I have always found it desirable to
 break them into smaller pieces. It speeds up editing, and for progrrams makes
 recompiling much faster since one need only redo affected portions, etc.
␈ CC: Jfr

∂04-JUN-75  1153		E,ALS
 Second installment
 I now have another version which never complains on /F but will not save the 
 new directory after a /F, in fact both directories are gone with a write out.
␈ CC: ME

∂04-JUN-75  1001		E,ALS
 It's partially fixed. It always keeps the old directory as a part of the text,
 telling you that it is doing this. It allows a change from readonly to
 readwrite but may get into trouble over this because of the old directory and
 because it has not saved the new paging before.
␈ CC: ME

∂04-JUN-75  0805		E,ALS
 I KNOW! It is not quite ready for public consumption.
␈ CC: rf

∂02-JUN-75  0913		E,ALS
 Can you come in to talk about the SOS problem? I am in the middle of fixing
 ETV so thaat there will be a /F mode which will allow one to page a /R file
 to any desired page size for convenience in reading it and this is a good time
 for me to fix your problem as well.
␈ CC: rf

∂02-JUN-75  0852		E,ALS
 Most things now work for /F. I am thinking about the following:
 1) Fix it so the default value for a /F value is set to 511 automatically when
 one types /R only. Since the line count is or will be set to zero every time a
 true FF is found, this would do nothing to files that are already paged to smaller
 limits.
 2) Test files that are to be formatted to see if they are paged already to less
 than 511 lines and if not to ask if this should be done. This request could be
 introduced during the directory making process and it would add very little to
 the running time if the pages were all shorter than this limit.
 3) Perhaps reverse the situation and fix it so that pages are always limited in
 size unless the user specifically requests otherwise.
␈ CC: ME

∂01-JUN-75  1813		E,ALS
 When you get the directory pointer invalid message it is wise to stop
 and fix things up. Unless you are in the readonly mode you can do this
 by the CONTROL . command. If it still complains then it is wise to
 leave ETV and reload the offending file. I am at home so I cannot
 look into your trouble very well at the moment but I have gotten a whole
 string of error messages which would indicate that you continued to 
 do what ever it was that led to the message many times, or that ETV was in a loop
 that you did not intercept.
␈ CC: BPM

∂01-JUN-75  1750		E,ALS
 Sorry I was not more specific.
 Mainly I fixwd up the matter of asking about formatting when one had
 typed /F. It seems to me that it should not be necessary to ask
 if it is OK to format when one has typed /F. So now it does not ask
 unless the file seems to be a binary file or if it is from a different
 PPN area than that of the person logged in. I also do not see the reason
 why one still has to store the /F value in FFLINE AND LATER TRANSFER IT TO
 EDFIL-2 so I fixwded it to store both places at once. THE
 remaining bad bug is that `fter one has done a /F/R and then tries to
 go back home with a H command the system still remembers and
 thinks that the home file is /F. I kept a copy of E as you left it as e.41
 so if you want to undo all of this it will be very easy.
␈ CC: me

∂01-JUN-75  1348		E,ALS
 Did you retype the UDP1: over again the second time/∨? If you did not
 this could be the trouble but probably you did and there is a bug. I
 have another related bug which may be due to the same thing. I will
 look into it on Monday.
␈ CC: jam

∂01-JUN-75  1134		E,ALS
 I fixed a few minor bugs but one remains that is very bad. This has to do with
 switching. I thought that if we stored /F in edfil-2 at once on page 63 some of
 these troubles would go away but they did not so I do not understand it correctly.
 This fix is now in however. I will not be able to work much till monday so
 good luck.
␈ CC: ME

∂31-MAY-75  0821		E,ALS
 That is not all that has to be fixed to make E work for the /F/R case. Suppose
 that you enter a file in this way, put some marks on page 1 then go to some other
 page, say 3. E will  copy through to page three ok but no record will be kept as
 to where in the specified records page 2 and page 3 start.
 Now you go back to page 2. Will E have to start all over and read from page 1
 to find the start of page 2? Now you decide to make some additions or deletions
 to page 2, giving the readwrite command  so that these will be accepted and thy to
 go back to your marks on page 3. What will happen? The straight forward way would
 be to redo the directory completely but this will mess up your marks. I hav figured
 how one might make a modification to the directory for the /F/R case to keep an
 additional number in addition to the record number to hold the line offset so that
 E does not have to start all over each time and this should be fairly simple as
 long as you do not make any changes to earlier pages but it would be very messy to
 change everything and create a new directory while taking proper care of marks.
 I am thinking about this but I think that I will ignore the readwrite change
 problem until I get the simple case working.
␈ CC: ME

∂31-MAY-75  0809		E,ALS
 What did you mean telling Taylor that ETV will not now handle SOS files? This
 is news to me. I thought that my fix worked OK. The only thing different should
 be that it tells you that you are trying to format an SOS file and requires
 confirmation that that is what you in fact want to do.	ALS
␈ CC: RF

∂30-MAY-75  1710		E,ALS
 RG is wrong. You can use ETV with SOS files. It does now tell you that
 you are working on an SOS file but if you tell it to cggo Ahread it does
 the right thhngs. It may be that some troubles might occur if you try to
 use ETV over the net. I do not know about thids.  I will get RF to explain
 his objections. 
␈ CC: RHT

∂30-MAY-75  1131		E,ALS
 I fixed the bug in /F and am a fair way along on the /R case. This gets a bit
 hairy if one lets the directory be created incrementally. The trouble is that
 the convenient time to introduce the FF seems to depend upon too many factors.
 I am sure that when I have thought it trrough properly I will find a better way
 than I now see how to do it. The code will definitely have to go somewhere near
 where we first put the /F stuff but certainly not exactly there.
␈ CC: ME

∂29-MAY-75  0946		E,ALS
 We were trying to do too much with too little. I am beginning to see what we
 need to do. We must differentiate between three different cases, that is
 1) /F switch only
 	Format the file with a FF and a new record and new page after every
 	FFLINE number of lines, create and save the new directory.
 2)/F and /N switches both used
 	Same as case 1) above except that the directory is creaated on page 0
 	and is not written out. The file will be rippled and padded out so that
 	the FF's are at the beginning of new records.
 3) /F and /N switches both used
 3) /F and /R switches both used
 	In this case we do not want to ripple the file so a pseudo directory
 is created on page 0 and a record should somehow be kept of the line count
 	at the start of each block so that ETV will not have to read from
 	the beginning every time a new page is switched to.
 One might expect a fourth case when /N, /R and /N are all three given, but
 in this case the /R would take precedence and the /N would simple be ignored.
 
 In case 1) the FFline value would not be written into EDFIL-2, since the value
 would be used only on the first formatting and it would not want to be
 remembered on file switching. This would also apply to case 2).
 in case 3) we would want to save the FFLINE value so that when the file is
 recalled by number we would recall the value and the same pseudo directory
 would be recreated.
␈ CC: ME
This is a file to save outgoing mail.